Such large delays in that function is a little too gross and not accurate.. Maybe there's something else the game calls a lot that should actually be slower by an amount that adds up to that.

Or maybe we'll just need to accept to forcibly downclock, since we know our CPU emulation really is too fast, due to not emulating the impact of cache misses. Or, since it seems the game's behavior is quite confusing, maybe it's really something else..

Just to add, the theory about game speed being tied to FPS is false, it's either full speed or half speed. FPS is variable depending on how heavy the scene is.

I think the confusion it's really more about me being ill and getting a fewer while looking at this and forgetting that PPSSPP setting for PSP CPU clock doesn't apply when leaving settings and returning to game, but only after game changes it or if we restart the game(loading savestates also work), so I kind of figured out how to work around the issue, but it wasn't perfect as it couldn't keep 60 fps constantly, so I OC PSP CPU, but saw no difference, so I then tried a different commonly repeated function and since the OC PSP CPU activated only then and I thought it didn't affect the issue at all, any results later just keep confusing me.

Actual behaviour isn't that messed up, some game function probably activates at wrong order or triggers incorrect amount of times due to PPSSPP being too fast and we end up with half of the speed, we can counter it without any code changes by the following:

• underclocking PSP CPU, but underclocking too much will ruin the framerate when more stuff happens on the screen, it'll also be variable,
• overclocking PSP CPU, it's perfect if we can achieve 60/60, but that's not ideal for weaker/mobile devices.

The hack here effectively works like underclocking, but without forcing variable/reduced fps to people that have hardware which can easily run OC PSP CPU.

Hmm... GetSystemTime should be a fast syscall isn't? since it's usually used to measure timeouts or other time-based calculation, if it's delayed by 70ms the outputted value might no longer be accurate.

If I understand, eating cycles does not mean delaying result, it just makes it heavier on the PSP CPU, at the same time lighter to emulate.

Either way this isn't correct change, just a hackish workaround to make it work out of the box, I'm not saying it's a good change, but speaking from PC user perspective much better than enforcing 30fps due to missunderstanding that it's speed would be tied to fps.

Correct change would mean to slow down every function to a realistic value, this would also fix other problems, but which is something that might never happen.

Ah right, the value is in cycles and not micro seconds, sorry i forgot, how much delay does 70k cycles be (based on the clock the game use by default)?

Btw, is this game one of those games that tried to render as much frames as possible (where downclocking it will lighten the burden)?

I guess it's 0,0315ms, but again, this doesn't delay result, we have different function "hleDelayResult" for that, this is just using "hleEatCycles" and it just reduces budget.

The problem is many PPSSPP functions doesn't eat out anything from that budget basically being free or using up a tiny constant value based on tests where in reality how long it takes might depend on things, when the game doesn't limit itself and just packs as much as it can within that budget, functions being free or very cheap makes it do much more work and also increases emulation requirements, ocassionally this also causes crashes or messes up animation speed or fps, it's pretty random and large variety of problems games in PPSSPP have still comes from that.

And yes, the game does render as much as it can, but it's not like GOW where it would go to 100+, with the change in here being between 58-60+ when little to nothing happens and drops to 30 or maybe less when a lot stuff happens on the screen. Without the change it also runs poorly and not being able to hold 100% fps even on hardware where it can keep much more with unthrottle and I'm not sure why is that as it seems counter-intuitive to affect emulation speed %, but this change works around that as well.

Actually that's not accurate. EatCycles is also a delay in PSP time, it's just that it doesn't allow the OS to change threads and do other work, while DelayResult allows that. So EatCycles is like a busy wait, and DelayResult a multi-tasking wait.

(Although it's not wrong to say that it reduces the CPU budget for the frame, because by delaying, it does that too, of course).